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Description 

REFERENCE TO RELATED APPLICATION 

5 [0001] This application claims the benefit of U.S. application number 60/437,869, attorney docket number 220635, 
filed January 3, 2003, entitled "SYSTEM AND METHOD FOR IMPROVED CLIENT SERVER COMMUNICATIONS," 
and incorporated herein by reference. 

FIELD OF THE INVENTION 

10 

[0002] This invention pertains generally to computer networks, and more particularly, to methods for communicating 
between client and server applications such as email applications. 

BACKGROUND OF THE INVENTION 

15 

[0003] Email has become an importantmethodforcommunicating. Email systemstypically include a server component 
(e.g., Microsoft Exchange Server) and a client component (e.g., Microsoft Outlook or Microsoft Outlook Express). These 
components are typically software applications that are configured to execute on computing devices (e.g., servers, PCs, 
laptops, and PDAs). 

20 [0004] Often, in order to facilitate communications, a client and server, such as client component and a server com- 
ponent of an email system, agree on a communications protocol. The protocol sets out the rules defining the expected 
behavior of each party during communications, for example, the expected sequence of request and response. Sophis- 
ticated protocols have rules for handling unexpected behavior. 

[0005] As client and server components are improved, the improved versions are distributed to end users. In order to 
25 take advantage of new component features and networkfeatures, it is often the case that a new communications protocol 

is invented. Where the installed base of server components is significant, a client component may have the ability to 
communicate, via a set of protocols, with selected previous versions of server components. 

[0006] It is sometimes the case that later protocols build upon earlier protocols rather than replacing them wholesale. 
In such a case, a later protocol may be built of protocol elements which can be enabled or disabled in order to simulate 
30 earlier protocols. Likewise, where the installed base of client components is significant, a server component may have 
the ability to communicate, via a protocol, with selected previous versions of client components. 
[0007] The invention provides such a system and method. These and other advantages of the invention, as well as 
additional inventive features, will be apparent from the description of the invention provided herein. 

35 SUMMARY OF THE INVENTION 

[0008] The present invention provides a system and method for improved client and server communications. More 
particularly, the invention is directed to an improved protocol that may be used for communication between a client and 
a server. The invention has particular relevance to an email server environment, but the features described herein may 

40 be utilized in other client and server networks. 

[0009] In accordance with an aspect of the present invention, an email server component may submit error information 
for a data object having an error instead of failing an entire set of responses because of an error in one. The email server 
component may receive, from an email client component, a request for a plurality of email data objects and an indication 
that the email client component is capable of handling an email data object having an error. In response to the request 

45 and the indication, the email server component may retrieve the plurality of email data objects, and, for each of the email 
data objects, if no error occurs in opening the email data object, transmit the email data object to the email client 
component If, however, an error occurs in opening the email data object, the email server component transmits an error 
message to the email client component. 

[001 0] In accordance with another aspect of the present invention, an email server component may provide progress 
50 data to an email client component so that the email client component may track the progress of a download from the 
email server component The email client component sends a request for a plurality of email data objects and an indication 
thatthe email client component is capable of handling progress mode data. In response to the request and the indication, 
the email server component retrieves the plurality of email data objects, and provides progress mode data to the email 
client component along with the plurality of data objects. The progress mode data may include a size of the plurality of 
55 the email data objects, the size of each of the objects, the number of the objects, whether the objects are folder associated 
information, additional information, or any combination of these items. 

[0011] In accordance with still another aspect of the present invention, a request sent by an email client component 
may indicate no limit for the size of a response to the request, allowing an email server component to fill a buffer, if 
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needed. The email client component sends a plurality of subrequests within a request, each of the subrequests requesting 
an operation at an email server component and including size information. In response to each subrequest, if the size 
information includes a size limit inside a range expected by the email server component, then the email server component 
limits a response to the size limit. If the size information includes a size limit outside a range expected by the email 
5 server component, then the email server component looks for a new size limit in the size infomnation. The new size limit 
may be arbitrary, such as "fill the available buffer." 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 [0012] FIG. 1 is a schematic diagram of computers connected by a network. 

[001 3] FIG. 2 is a schematic diagram illustrating an exemplary computer system usable to implement an embodiment 

of the invention. 

[001 4] FIG. 3 is a schematic diagram depicting an environment with multiple versions of both email client components 
and email server components. 

15 [0015] FIG. 4 is a protocol diagram showing an example of a protocol negotiation procedure between an email client 
component and an email server component. 

[001 6] FIG. 5 is a schematic diagram showing an example email network in which email client components and email 
server components have fixed size communication buffers. 

[001 7] FIG. 6A is a protocol diagram showing an example protocol requiring two request-response cycles to complete 
20 a fast transfer operation. 

[001 8] FIG. 6B is a protocol diagram showing an example protocol requiring asingle request-response cycle to complete 
a fast transfer operation. 

[0019] FIG. 7A is a flowchart depicting an example procedure for sending an email message body to an email client 
component. 

25 [0020] FIG. 7B is a flowchart depicting a procedure for sending an email message body to an email client component 

in accordance with an aspect of the present invention. 

[0021] FIG. 8A is a sequence diagram illustrating a full item transfer mode. 

[0022] FIG. 8B is a sequence diagram illustrating a headers first transfer mode. 

[0023] FIG. 8C is a sequence diagram illustrating a headers only transfer mode. 
30 [0024] FIG. 8D is a sequence diagram illustrating an exception to a headers first or a headers only transfer mode. 

[0025] FIG. 9 is a schematic diagram showing an email client component's home email server component being 

changed overtime. 

[0026] FIG. 1 0 is a protocol diagram showing an example protocol for synchronizing email folders between an email 
client component and an email server component. 
35 [0027] FIG. 1 1 A is a flowchart depicting an example procedure for optimizing part of a stateblob. 

[0028] FIG. 11 B is a flowchart depicting a procedure for optimizing part of a stateblob in accordance with the present 
invention. 

[0029] FIG. 1 2 is a schematic diagram illustrating an email folder hierarchy. 

[0030] FIG. 1 3 is a protocol diagram showing an example protocol for synchronizing and maintaining synchronization 
40 of an email message store in accordance with an aspect of the present invention. 

[0031] FIG. 14Ais a protocol diagram showing an example protocol for communicating error information at the ROP 
level. 

[0032] FIG. 14B is a protocol diagram showing an example protocol for communicating error information on a per 

message basis in accordance with an aspect of the present invention. 
45 [0033] FIG. 1 5A is a flowchart depicting a procedure for generating error information at the ROP level. 

[0034] FIG. 15B is a flowchart depicting a procedure for generating error information on a per message basis in 
accordance with an aspect of the present invention. 

[0035] FIG. 1 6A is a protocol diagram showing an example protocol for carrying out a fast transfer operation. 
[0036] FIG. 1 6B is a protocol diagram showing an example protocol for providing progress information while carrying 
50 out a fast transfer operation in accordance with an aspect of the present invention. 

[0037] FIG. 1 7A is a flowchart depicting a procedure for streaming out a set of messages. 

[0038] FIG. 17B is a flowchart depicting a procedure for streaming out a set of messages along with progress information 
in accordance with an aspect of the present invention. 

[0039] FIG. 1 8 is a schematic diagram of multiple email client components being notified as the result of a change to 
55 the same data object at an email server component. 

[0040] FIG. 1 9A is a flowchart depicting a procedure for notifying multiple subscribers. 

[0041] FIG. 19B is a flowchart depicting a procedure for notifying multiple subscribers in accordance with an aspect 
of the present invention. 
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[0Q42] FIG. 20 is a flowchart depicting a procedure for providing an email message that uses a desired code page in 
accordance with an aspect of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

5 

[0043] Prior to proceeding with a description of the various embodiments of the invention, a description of the computer 
and networking environment in which the various embodiments of the invention may be practiced will now be provided. 
Although it is not required, the present invention may be implemented by programs that are executed by a computer. 
Generally, programs include routines, objects, components, data structures and the like that perform particular tasks or 

^0 implement particular abstract data types. The term "program" as used herein may connote a single program module or 
multiple program modules acting in concert. The term "computer" as used herein includes any device that electronically 
executes one or more programs, such as personal computers (PCs), hand-held devices, multi-processor systems, 
microprocessor-based programmable consumer electronics, network PCs, minicomputers, tablet PCs, mainframe com- 
puters, consumer appliances having a microprocessor or microcontroller, routers, gateways, hubs and the like. The 

15 invention may also be employed in distributed computing environments, where tasks are performed by remote processing 
devices that are linked through a communications network. In a distributed computing environment, programs may be 
located in both local and remote memory storage devices. 

[0044] An example of a networked environment in which the invention may be used will now be described with reference 
to FIG. 1. The example network includes several computers 10 communicating with one another over a network 11, 

20 represented by a cloud. Network 1 1 may include many well-known components, such as routers, gateways, hubs, etc. 
and allows the computers 10 to communicate via wired and/or wireless media. When interacting with one another over 
the network 11, one or more of the computers may act as clients, servers or peers with respect to other computers. 
Accordingly, the various embodiments of the invention may be practiced on clients, servers, peers or combinations 
thereof, even though specific examples contained herein do not refer to all of these types of computers. 

25 [0045] Referring to FIG. 2, an example of a basic configuration for a computer on which all or parts of the invention 
described herein may be implemented is shown. In its most basic configuration, the computer 10 typically includes at 
least one processing unit 1 4 and memory 1 6. The processing unit 1 4 executes instructions to carry out tasks in accordance 
with various embodiments of the invention. In carrying out such tasks, the processing unit 14 may transmit electronic 
signals to other parts of the computer 10 and to devices outside of the computer 10 to cause some result. Depending 

30 on the exact configuration and type of the computer 10, the memory 16 may be volatile (such as RAM), non-volatile 
(such as ROM or flash memory) or some combination of the two. This most basic configuration is illustrated in FIG. 2 
by dashed line 18. Additionally, the computer may also have additional features/functionality. For example, computer 
1 0 may also include additional storage (removable 201 and/or non-removable 202) including, but not limited to, magnetic 
or optical disks ortape. Computer storage mediaincludes volatile and non-volatile, removable and non-removable media 

35 implemented in any method or technology for storage of information, including computer-executable instructions, data 
structures, program modules, orotherdata. Computerstorage media includes, but is not limited to, RAM, ROM, EEPROM, 
flash memory, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic 
diskstorageorother magnetic storage devices, or any other medium which can be used to stored the desired information 
and which can be accessed by the computer 1 0. Any such computer storage media may be part of computer 10. 

40 [0046] Computer 1 0 preferably also contains communications connections 205 that allow the device to communicate 
with other devices. A communication connection is an example of a communication medium. Communication media 
typically embody computer readable instructions, data structures, program modules or other data in a modulated data 
signal such as a carrier wave or other transport mechanism and includes any infomnation delivery media. By way of 
example, and not limitation, the term "communication media" includes wired mediasuch as a wired network or direct -wired 

45 connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term "computer-readable 
medium" as used herein includes both computerstorage media and communication media. 

[0047] Computer 10 may also have input devices 204 such as a keyboard, mouse, pen, voice input device, touch 

input device, etc. Output devices 203 such as a display 20, speakers, a printer, etc. may also be included. All these 

devices are well known in the art and need not be discussed at length here. 
50 [0048] The present invention is directed to a system and method for improved client and server communications, and 

more particularly is directed to an improved protocol that may be used for communication between a client and a server. 

The invention has particular relevance to an email server environment, but the features described herein may be utilized 

in other client and server networks. For ease of description, however, the invention is described with reference to a 

client/server email environment. 
55 [0049] The present invention may be implemented in a client/server environment having two or more versions of client 

applications or components, and/or two or more versions of server applications or components. To this end, FIG. 3 

illustrates a block diagram showing multiple versions of both client and server components in a networkemail environment. 

In general, the client and server components are configured so that they are backwardly compatible. That is, a client 
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component is capable of communicating with recent and legacy versions of server components, and vice versa. A set 
of protocols are established to communicate between the multiple versions. The set of protocols may constitute several 
different protocols, each being self-contained. Alternatively, a set of protocol components may be available, and particular 
components are used to configure particular protocols within the protocol set. 

5 [0050] In any event, in the network email environment shown in FIG. 3, a most recent version email client component 
303 communicates best with a most recent version email server component 306 using a protocol 307. However, the 
most recent email server component 306 is also capable of communicating with selected previous version email client 
components, for example, email client component 302 and email client component 301, using other protocols (e.g., 
protocols 308 and 309 in FIG. 3) in a protocol set. Email client component 303 is also able to communicate with selected 

^0 previous version email server components, for example, email server component 305 and email server component 304, 
using protocols such as the protocols 31 0 and 31 1 . 

[0051] Generally, as used herein, for the purposes of describing the protocol of the present invention, a "most recent" 
email (server or client) component, or a most recent version of an email (server or client) component, is a server or client 
component that is aware of the new feature or features being described, and can utilize, implement, and/or act on those 

15 features. Although the terms are used throughout this document to describe client and servercomponents that are aware 
of the various aspects of the protocol of the present invention, the terms also include components that are aware of only 
the particular aspect being described, or more than one aspect being described. Likewise, a "previous" email component 
or previous version of an email component is a component that is not aware of, and cannot act upon the aspects of the 
protocol of the present invention. 

20 [0052] A protocol negotiation procedure is often used to establish a protocol between a client and a server (e.g., the 
most recent version email server component 306 and the most recent version email client component 303). Although 
such protocol negotiations are known, a brief description of a protocol negotiation procedure between email client 
component 401 (FIG. 4) and email server component 402 (also FIG. 4) is provided for the benefit of the reader. Early 
in a communication session between email client component 401 and email server component 402, email client com- 

25 ponent 401 sends email server component 402 a message 403 that includes client version information, for example, in 
the form of a client component version stamp. Email server component 402 responds to message 403 with message 
404 that includes server version information, for example, in the form of a server component version stamp. 
[0053] The client and server version information may be used in a variety of ways to attempt to establish communication 
between the email client component 401 and the email server component 402. For example, version information may 

30 be used to select a suitable protocol for continued communications, or to determine if further communications are even 
possible. In establishing a protocol, version information may be used to enable and/or disable specific available protocol 
aspects or components, for example. 

[0054] An email server component may receive and process requests from multiple email client components in parallel. 
Where a single client is shown, unless explicitly stated otherwise, it is merely to simplify the figures and accompanying 
35 explanation. 

[0055] The email network of the present invention utilizes request and response exchanges to pass queries and data 
between client and server components in the network. In practice, the performance of a protocol may be effected by the 
underlying communications network transport mechanism used to implement communications between clients and 
servers in an email network. For example, in an email network that uses remote procedure calls (RPCs) as the underlying 
40 communications network transport mechanism, it may be much more efficient to make a single remote procedure call 
of larger size (e.g., 32KB) than to make several remote procedure calls of smaller size (e.g., 2KB). One way known to 
improve performance in such an email network is to buffer multiple requests and/or responses for transmission in a 
single remote procedure call. 

[0056] As an example, FIG. 5 shows a request and response exchange between an email client component 501 and 
45 an email server component 502. The email client component 501 and the email server component 502 each have fixed 
sized communication buffers 503, 504, 505 and 506. The buffers 503, 504, 505 and 506 are reserved areas of memory 
for temporarily holding data. Email client component 501 begins a request- response cycle by filling buffer 503 with one 
or more sub-requests or remote operations (ROPs) before transmitting the contents of the buffer 503 to buffer 504. 
[0057] After being received in the buffer 504, each ROP is processed in order by email server component 502 and 
50 the corresponding result written to buffer 505. Each ROP does produce some result. The result may include data 
requested by email client component 501, for example, a particular set of email messages. Email server component 
502 monitors buffer 505 and when it is nearly full (e.g., less than 8KB remaining), email server component 502 writes 
any unprocessed ROPs to the end of buffer 505 and transmits buffer 505 to buffer 506. Email client component 501 
then begins a new request-response cycle by writing unprocessed ROPs to buffer 503 for resubmission to email server 
55 component 502 when buffer 503 becomes full again. 

[0058] The size of a response Is typically larger on average than the size of a request. For this reason, the size of 
response buffers 505 and 506 are typically configured to be larger than the size of request buffers 503 and 504. In one 
embodiment of the invention, the optimal size of the response buffers 505 and 506 was detennined to be 96KB for a 
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size of 32KB for request buffers 503 and 504, a ratio of 3 to 1 . In one ennbodiment, the ennail client connponent is capable 
of configuring the size of any of the buffers 503, 504, 505 and 506. 

[0059] Some ennail networl<s that utilize buffers, for example the email network shown in FIG. 5, may employ a fast 
transfer mode between an email client component and an email server component. Fast transfer mode includes requests, 

5 such as ROPs, by a client that are divided into at least two kinds: requests that result in an initialization of a fast transfer 
data source at the server, and requests that result in the efficient transfer of data from the fast transfer data source to 
the client. The fast transfer data source may be, for example, a database table. The fast transfer data source serves as 
a ready temporary store of data that enables later requests for the data to be serviced with less delay than would otherwise 
be possible. Sometimes the second kind of fast transfer mode request seeks to achieve efficient transfer of data by 

^0 explicitly specifying the size of the response, for example, the size of the response may be set to the size of the entire 
client receive buffer less response overhead. 

[0060] FIG. 6A shows a fast transfer operation having at least two request-response cycles. In a first request 601 a 
ROP (e.g., FXPrepare) initializes a fast transfer data source on server 502. At the server, only FXPrepare is processed 
(i.e., the fast transfer data source is initialized) and its result is returned in a first response 602. In a second request 603 

15 a ROP (e.g., FXGetBuffer) requests the server to fill the buffer 505 from the fast data source. The server empties the 
fast data source into the buffer, and returns the result in a second response 604. If the output buffer 505 for the email 
server component fills before the fast data source is emptied, additional FXGetBuffer ROPs may be required. 
[0061] FIG. 6B shows a fast transfer operation having only a single request-response cycle. In a first request 605, 
both FXPrepare and FXGetBuffer are processed by email server component 502 and the results of both operations are 

20 returned in first response 606. The result of FXPrepare is available to FXGetBuffer at email server component 502 
because part of each buffer 503, 504, 505 and 506 is explicitly defined as a shared data table. It is desirable to reduce 
the number of request-response cycles because it results in a more efficient transfer of data. A fast transfer operation 
having more than only a single request-response cycle may occur when buffer 505 is too full to hold the result of an 
FXGetBuffer ROP. 

25 [0062] Itwill be appreciated that the ROPs of FIGS. 6Aand6Band like figuresthroughoutthis application are schematic 
in that they may be implemented in practice by a series of ROPs, unless specifically stated otherwise. 
[0063] Typically, the size of a ROP result is different from the size of a ROP request. It is not always possible to predict 
the size of a ROP result. When data compression techniques are used to reduce the size of a ROP result, it is even 
more difficult to predict the size of a ROP result. Not being able to predict the size of a ROP result can prevent manual 

30 tuning of a protocol to minimize the number of request-response cycles required to complete particular client operations, 
for example, to ensure that all new messages are downloaded to the client in a single request-response cycle. Manual 
tuning of a protocol includes manually configuring the sequence and/or size of protocol requests, responses and/or ROPs. 
[0064] In accordance with one aspect of the present invention, the number of request-response cycles is automatically 
minimized by specifying that key ROPs (e.g., FXGetBuffer) are free from the requirement to predict the size of their 

35 result. Instead, such ROPs are processed by email server component 502 until the limit of buffer 505 (which is the same 
as buffer 506) is reached. 

[0065] As an example, in an environment that includes multiple versions of email server components, separate ROPs 
may be defined for previous version server components and recent version server components. The recent versions 
are free from the requirement to predict the size of their result. The characteristics for these ROPs are set forth in the 
40 following table: 



45 



50 
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ROP that may be used by a 
protocol for 
cominunicating yfUh 
previous version servers 


ROP that may be used by a 
protocol for 

communicating with most 
recent version servers 


ROFID 


FXGetBuffw 


FXGetBuffer 


Parameters used in 

iniiltinle mnfl»c 


Reauired size: die size that 


Required size: is set to a 


liic scTVcT musi rcscTvir m iis 
output bufifer. 


Value DEyunu ui6 maxinium 
expected by the previous 
version, for example, to a 
value greater than 32KB. 
This signals the server to 
look for the new size limit 





ROP that may be used by a 
protocol for 
communicating ivitli 
previous version servers 


ROP that may be used by a 
protocol for 

comma aicating with most 
recent version servers 






parameter. 


New parameters 


n/a 


Size limit: informs the server 
of the limit up to which the 
server may fill its output 
buffer. 



[0066] The ROPs for previous version server components are sinnilar in construction to existing, prior art ROPs. That 
is, the ROPs predict and dictate a size in the output buffer (e.g., send buffer 505) that must be reserved for holding a 
response. In contrast, the dictated size for the output buffer for a nnost recent version of a server component is not 
predicted, but instead is set to a value beyond the maximum expected by the previous version server components, for 
example, to a value greater than 32KB. The fact that the size of the output buffer is defined beyond a value expected 
by the server component signals the server component to look for a new size limit parameter, which may be, for example, 
a filling of the output buffer for the server component. These characteristics automatically minimize the number of 
request-response cycles, with only a small increase in the complexity of an email server component that processes the 
ROPs 

[0067] Note that the order of parameters shown in the table above and in like tables throughout this application do 
not necessarily correlate with the order that, for example, the parameters are transmitted over the network or stored in 

memory by either an email client component or an email servercomponent, unless accompanied by an explicit statement 
to the contrary. In addition, unchanged parameters may be omitted for the sake of clarity. 

[0068] In an email network, one of the typical duties of a protocol is to achieve the transfer of data objects, for example, 
email messages, between email client components and email server components. Furtherexamplesof such data objects 
include email folders which may contain email messages and other data objects, and folder associated information (FAI) 
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data objects which may, for example, contain rules for processing email messages, or define how the data objects 
contained by a folder will be displayed. Data objects may be opaque to an email client component; that is, an email client 
component may have no means of interpreting the contents of the data object. Alternatively, data objects may be 
composed of named properties, for example, an email message may comprise properties named "to," "from," "subject," 

5 "importance," "body 1 ," "body 2," "body 3," "attachment 1 ," "attachment 2," and so on. 

[0069] One advantage of email networks where data objects may be composed of named properties over email 
networks where data objects are opaque is the potential to improve protocol performance because of the ability of a 
protocol to transfer only part of a data object. Having named properties permits particular properties of the data object 
to be transmitted without transmitting the entire data object. 

^0 [0070] For example, an email message may be composed of a set of header properties and a set of body properties. 
The needs of an email client component may be such that a protocol may transfer the header properties first and then 
the body properties later or not at all. This feature permits a user to view the header information for several messages 
priorto the entirety of all the messages being downloaded. Using this feature, a more fine-grained control over bandwidth 
utilization may be obtained by the client component, which may positively effect protocol performance. In addition, a 

15 client component may use this feature to result in lower bandwidth utilization (for example, bodies may be downloaded 
for only selected headers), which is particularly desirable in low bandwidth environments. 

[0071] The performance of the protocol does not necessarily increase If the server component is configured to send 
body and header properties in two separate re quest- response cycles (i.e., one each for the header and the body). For 
example, if the needs of the email client component were such that it required both header and body properties at the 

20 same time, then the performance of the protocol might be decreased verses a situation where a single request-response 
cycle could retrieve both the header and the body. Thus, the simple act of enabling data objects to be composed of 
named properties is not itself enough to automatically result in improved protocol performance. Achieving improved 
protocol performance does depend on the choice of properties that may make up a data object and how they may be 
used by a protocol. That choice may depend on a number of factors including the needs of most recent and previous 

25 version email client components, and the needs of most recent and previous version email server components. Examples 
of email client component needs include satisfying different levels of urgency for the display of different information and 
complying with preferences set by an email client component user. Examples of email server component needs include 
efficient storage and retrieval of data and efficient processing of protocol requests. 

[0072] Conventional prior art email environments utilize data objects that may be composed of named properties, for 
30 example, an email message that may include a header set and a body set of named properties so that the two sets may 
be requested and/or processed separately. Another prior art example is an email message where the body set of named 
properties includes multiple versions of the email message body, for example, in multiple email message formats such 
as plain text, hypertext mark-up language (HTML), rich text fonnat (RTF) and so on. In this situation, prior art email 
server components may respond to a protocol request for the body of the email message in a number of ways. The 
35 lowest complexity response may be to send all versions of the email message body but this response may result in 
increased bandwidth utilization. 

[0073] FIG. 7A depicts part of a procedure that a previous (prior art) version email server component does use to 
respond in this situation. In step 701 , the email server component examines the format of each email message body. If 
one of the formats is a predetermined standard format (e.g., RTF), then the procedure moves to step 703 and the 
40 standard format email message body is sent to the requesting email client component. If none of the formats is a 
predetennined standard format, then step 701 branches to step 702 where one of the email message body versions is 
converted to the standard format. The subprocedure depicted by FIG. 7A may also be used when there is only a single 
version of an email message body but the email message body may not be in a standard format that is required by a 
protocol. 

45 [0074] FIG. 7B depicts part of a procedure used by a most recent version email server component in accordance with 
the present invention. In step 704, a protocol request that results in this subprocedure being used by an email server 
component is examined for a BEST_BODY flag. The flag in this example and the other flags used herein are used to 
the email server component that the email client component is a most recent version and desires to implement the 
function associated with the flag. Other indications may be used. For example, the function may be implemented by 

50 default If a most recent email client component is detected. 

[0075] In any event, If the BEST_BODY flag is not found, then step 704 branches to step 701, and continues as 
described with reference to FIG. 7A. 

[0076] If the flag is found, the procedure moves to step 705, where the best email message body is selected for sending 
to the requesting email client component. If there Is only a single email message body associated with the requested 
55 email message, then it is the best. If there are several email message bodies available, for example, with different 
formats, then the email servercomponent chooses the bestfrom among them according to, for example, a predetermined 
ranking of email message body formats (e.g., RTF, HTML, plain text). The process then proceeds to step 703, where 
the chosen email message body is sent to the email client component. In this embodiment, the email client component 
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may be capable of displaying multiple email message body fomriats thus freeing the email server component from the 
requirement to convert email message bodies to a standard format. In addition, the email client component may convert 

the best email message body to a different format, if desired. 

[0077] Because the email sen/er component is relieved of the task of converting email message bodies, the present 
5 invention provides improved performance. In addition, a most recent version email server component may respond to 
protocol requests from a previous version email client component with only a moderate increase in complexity. 
[0078] ROPs may be used to achieve the replication of an email folder between an email server component and an 
email client component. A request to synchronize a folder may be made, for example, by a SynchFolder ROP. Where 
an emailclientcomponentiscapableof displaying non-standard email message body formats, it may set the BEST_BODY 
^0 flag in the SynchFolder ROP to indicate that the email server component may select the best format from among the 
available email message bodies, rather than requiring the server to return an email message body in a standard format. 
An emailservercomponentmay properly process ROPs both with and without the BEST_BODYflag with only a moderate 
increase in complexity. ROPs for communicating with previous version and most recent version servers may include, 
for example, the characteristics set out in the table below: 

15 





ROP that may be used by a 
protocol for 
communicatiog with 
previous version servers 


ROP that may be used by a 

protocol for 

coinmunicatiDg with most 
recent version servers 


ROP ID 


SynchFolder 


SynchFolder 


Wew paraineten 


n/a 


BEST BODY flae; if set. 


the email server component 
chooses the best email 
message body to send to the 
email client component. 
Conversion of the email 
message body to a 
predetennined standard 
format is unnecessary. 



[0079] FIGS. 8A-8C show several different existing modes of transfen^ing a set of ennail messages between an email 
40 server component and an email client component. For each mode, each email message has named properties including 
a header set and a body set, and several email messages are contained in a folder. FIG. 8A illustrates a full item transfer 
mode. The illustration shows a first email message header 801 being transferred and then a first email message body 
802 before a second email message header 803 and then a second email message body 804 and so on until the set of 
email messages has been transferred. FIG. SB illustrates a headers first transfer mode. In this mode, a first email 
45 message header 805 is transferred and then a second email message header 806 and so on until all the email message 
headers have been transferred and only then is a first email message body 807 transferred and then a second email 
message body 808 and so on until the set of email messages has been transferred. FIG. 80 illustrates a headers only 
transfer mode. As the name suggests, only the email message headers 809 are transferred in response to a request to 
transfer a set of email messages. Email message bodies 81 0 will only be transferred in response to an additional explicit 
50 request. In any of these modes, the transfer sequence may be temporarily interrupted by a higher priority email client 
component request, for example, for a particular email message body. 

[0080] An email folder is an example of a target for a request to transfer a set of email messages. However, an email 
folder may contain data objects other than email messages. As discussed above, transfer modes are often defined with 
reference to email message headers and email message bodies, such as the headers first and headers only transfer 
55 modes. In such transfer modes, an attempt to transfer data objects for which a header set of named properties and/or 
a body set of named properties may not be well defined may result in protocol failure. One aspect of the invention avoids 
this situation by providing that data objects for which a header and/or body set of named properties is not well defined, 
may always be transferred in whole rather than in part. This embodiment may be illustrated by example with FIG. 8D. 
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In this example, transferal between an ennall server connponent and an email client component may be occurring in a 
headers only mode. Accordingly, a first email message header 81 1 is transferred and then data object 812 becomes a 
next candidate for transferal. The header set of named properties is not well defined for a data object 812, such as FAI, 
so the entire data object is transferred. A next candidate for transferal does have a well defined header set of named 

5 properties (i.e., the candidate data object does possess all the named properties explicitly defined by the email client 
component as belonging to the header set of named properties) and so only an email message header 81 3 is transferred. 
[0081] An example of one way to implement this aspect of the present invention is by using a flag, such as 
IGNORE_MODE ON FAI, that may be included in a synchronization ROP, such as Synch Folder ROP described above. 
An email server component may properly process ROPs both with and without a IGNORE_MODE_ON_FAI flag with 

^0 only a moderate increase in complexity. ROPs may include the characteristics set out in the table below to achieve the 
replication of an email folder between an email server component and an email client component: 





ROP that may be used by a 
protocol for 
communicatiDg with 
previous version servers 


ROP that may be used by a 
protocol for 

communicating with most 
recent version servers 


ROP ID 


SynchFolder 


SynchFolder 


New parameters 


n/a 


IGNORE MODE ON FAI 


flag: if set, then for data 
objects, such as FAI, that do 
not have a well defined set 
of header and/or body 
named properties, the email 
server component may 
respond to a transfer request 
with the entire data object 
regardless of the prevailing 
transfer mode. 



40 [0082] Email nnessages are typically addressed to one or more email network users. An email message may be 
considered delivered if it is accepted by an email server component for storage. An email network may have several 
email server components. Typically, an email network protocol has some strategy for limiting the number of email server 
components that an email network user must check for new messages. A common example is the home server strategy 
which provides that email messages addressed to a particular email network user will only be accepted by one particular 

45 email server component, called the user's home server. In such a case, an email client component may be configured 
to consider only the home server when, for example, periodically checking for new email messages or registering for 
notification of new email messages. 

[0083] FIG. 9 shows that even a simple home server strategy example may have complications. In the example 

illustrated by FIG. 9, a particular email server component 901 is first designated as the home server for a particular email 
50 network user. Over time, the designated home server for the user Is changed to different email server components 903 
and 905, typically for administrative reasons. The email server components 901, 903 and 905 may, for example, be 
physically different, or logically different, or be different versions. Email client component 902 may communicate only 
with email server component 901 from time To until time T^, then email client component 904 may communicate only 
with email server component 903 until time T2, and then email client component 906 may communicate only with email 
55 server component 905. The email client components 902, 904 and 906 may be the same or different. Email server 
components 901 and 903 may or may not exist after time T2. These complications are particularly relevant to email 
message store replication which is discussed next. 

[0084] Email messages may be stored by an email server component in an explicit email message store which may, 
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for example, be implemented using well known database technologies. An email server component may have one or 
more such message stores. An email network user may have a home message store. Changing home message stores 
may have the same effects as described for changing home servers. 

[0085] Some email network protocols include an ability to replicate parts of an email message store to a storage facility 

5 local to an email client component. Replication of parts of a remote email message store to a local email storage facility 
may improve protocol performance and/or perceived protocol performance by, for example, replicating all new email 
messages to the local email storage facility in advance of an explicit email network user request to view them. Such 
replication may also provide additional email client component functionality, for example, enabling an email network 
user to view an email message during network connectivity interruptions. 

10 [0086] In an email network environment, simple replication may quickly become inefficient. For example, if an email 
server component has one email message associated with a particular email network userand that message has already 
been replicated at the client component for the network user, and a new email message arrives for that email network 
user, then it is still required that two email messages must be sent in response to a simple replication request. If another 
new email message arrives after replication of the two email messages, then it is still required that three email messages 

15 must now be sent in response to a simple replication request and so on. Some email network protocols have provided 
for an incremental replication of email message stores to alleviate this problem. In an incremental replication, only 
changes to an email message store that occurred after a previous successful incremental replication must be sent in 
response to a replication request, for example, where the only change since the last successful incremental replication 
is the arrival of a new email message, then only the new email message need be sent in response to an incremental 

20 replication request. 

[0087] FIG. 1 0 shows a more detailed example of a protocol that provides for incremental replication. An email message 
store may be subdivided Into email folders. Each email folder may be replicated independently of the others, providing 
for a more fine-grained control overthe replication process. In this example, the incremental replication process is termed 
synchronization because it includes the propagation of changes from email client component 501 to email server com- 

25 ponent 502 as well as from email server component 502 to email client component 501 . Following a synchronization 
request 1 001 , aSynchFolder ROP Is processed by email server component 502. The ROP Includes afolderlD parameter 
(not shown) and a stateblobo parameter. The folderlD parameter identifies an email folder that Is the target of the 
synchronization request 1001 . The stateblobg parameter contains information that allows email server component 502 
to determine what changes, if any, have occurred to the email folder since it was last synchronized. If request 1001 

30 represents the first ever synchronization request for the target folder by email client component 501 , then email server 
component 502 determines if the target email folder in the email message store has changed in comparison to an empty 
folder. In response 1002 to request 1001, email server component 502 sends any changes to email client component 
501 including any email messages and/or other data objects that have been added to the target folder and a list of any 
email messages and/or other data objects that have been deleted from the target folder. The email server component 

35 502 also creates a new slateblob, representing the state of the target folder as it will be on email client component 501 
immediately following the synchronization and also sends that stateblob^ in response 1 002. When email client component 
501 sends the next synchronization request 1003 for the same folder as in request 1 001 , then request 1003 will include 
as a parameter the same stateblob-i that was returned with response 1 002. As before, email server component 502 will 
use the information contained in stateblob-, to determine what changes, if any, have occurred in the target folder and 

40 send those changes along with a newly created stateblobg back to email client component 501 in response 1 004. 

[0088] If a stateblob data object is large in size, it may adversely effect protocol performance because It is sent to and 
from an email server component with, for example, every email folder synchronization request. In some email network 
protocols that provide for email folder synchronization, the stateblob may, in large part, be made up of a set of message 
changelD data objects that identify changes to email messages that have been seen by an email client component. An 

45 email message change may be said to have been seen by an email client and/or server component when the changed 
email message is transferred to that component. 

[0089] One goal of a message changelD data object may be to uniquely identify a change to an email message in the 
context of an entire email network. In an email network that employs a home server strategy, a user's home server may 
be responsible for associating a message changelD data object with a previously unseen email message change. For 

50 example, a home server may employ message changelD data objects comprising a serverlD data object and a serial 
number. A serverlD data object may uniquely identify an email servercomponent in the context of an entire email network 
using well known techniques such as globally unique identifiers. Where such identifiers are themselves large in size, 
the serverlD data object may instead be an index into an identifier lookup table maintained by the email servercomponent. 
The serial number may be provided by a counter, for example, six bytes in width, local to an email server component, 

55 that is incremented whenever the email server component accepts a previously unseen email message for storage. 
[0090] For discussion purposes, a message changelD data object may be represented by, for example, "Si:1" where 
'Si' represents the serverlD data object for a first email server component and '1 ' represents a serial number. A set of 
message changelD data objects may be represented by, for example, "Sy^, S-,:2, S-|:3" where "Si:1 ", "Si:2" and "Si: 



12 



EP 1 631 025 A2 



3" are consecutive message changelD data objects employed by an email server component with serverlD S^. 
[0091] Where a stateblob is made up, in large part, of a set of message changelD data objects representing email 
message changes seen by an email client component (a "Message Changes Seen" set), some techniques have been 
developed to encode the set in order to reduce its size, for example, the set "Si:1 , S^:2, S^:3, S^'A" maybe encoded as 

5 "S^:1-4". In addition, an email server component may ensure that the serial numbers it uses are always increasing. In 
that case a non-contiguous Message Changes Seen set, for example, "S^:! , S^:3, S^:5, S^:/", may be encoded as "S^: 
1-7", that is, as a range including the minimum and maximum serial numbers, without loss of functionality. 
[0092] In a scenario depicted by FIG. 9, a Message Changes Seen set may include message changelD data objects 
that were created by email server components (e.g., S^, Sg) other than the current home server (e.g., S3). A message 

^0 changelD data object created by the cun"ent home server may be termed a native message changelD, a message 
changelD data object created by other email server components may be termed a foreign message changelD. Email 
network protocols for communicating with previous version email server components have not provided for the optimi- 
zation of non-contiguous foreign message changelD sequences as a range including the minimum and maximum serial 
numbers on a per email server component basis. The following table illustrates a benefit of including such optimization 

15 in an embodiment of the present invention: 





Optimization used by a 


Optimization used by a 




previous version server 


most recent version server 




(current home server S3) 


(current home server S3) 


Message Changes Seen set 


Si:l,Si:3, Si:5, Si:7 


before optimization 


82:1,82:3, 82:5,82:7 




83:1, 83:3, 83:5. 83:7 


Message Changes Seen set 


Si:l,Si:3.Si:5,Si:7 


Si:l-7 


after optimization 


82: li 82:3, 82:5, 82:7 


82:1-7 




83:1-7 


83:1-7 



35 [0093] One embodiment of the present invention uses ROPs that include the characteristics set out in the table below 

to achieve the synchronization of an email folder between an email server component and an email client component. 
An email server component may implement the improved stateblob encoding technique with only a moderate increase 
in complexity. 
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ROP result that may be 
used by a protocol when 
communicating with 
previous version servers 


ROP result that may be 
used by a protocol when 
communicating with most 
recent version servers 


ROPID 


SynchFolder 


SynchFolder 


Unchanged parameters 
used in a new mode 


stateblob: optimization not 
including non-contiguous 
sets of foreign message 
changelD data objects. 


stateblob: improved 
optimization including non- 
contiguous sets of foreign 
message changelD data 
objects. 



[0094] FIG.1 1 A and FIG. 1 1 B depict a difference between a subprocedure that may be used by a previous version 
server and a nnost recent version server, respectively, to respond to a SynchFolder ROP. FIG. 1 1 A shows steps 11 01 , 
1102 and 1103. At step 1101, an initial Message Changes Seen set is constructed. At step 1102, nnembers of the 
Message Changes Seen set that are native message changelD data objects are optimized. At step 1 1 03, the optimized 
Message Changes Seen set is added to the stateblob data object that may be sent with a response to an email client 
component that requested the synchronization. FIG. 1 1 B includes additional step 1 1 04 which shows members of the 
Message Changes Seen set that are foreign message changelD data objects also being optimized before the Message 
Changes Seen set, now with improved optimization, is added to a stateblob data object in step 1 1 03. 
[0095] While subdividing an email message store into email folders does provide for a more fine-grained control over 
the synchronization process, it does not automatically provide for an improvement in protocol performance and it may 
result in a degradation in protocol performance. For example, some protocols require that each message store folder 
be synchronized separately. Each synchronization operation typically has some overhead and that overhead may be 
significant. Synchronizations operations that utilize stateblob data objects are an example of operations that may have 
significant overhead. In the case of synchronizing an entire message store, protocols that require each message store 
folder to be synchronized separately may be at a disadvantage compared to protocols that require fewer synchronization 
operations. 

[0096] Synchronizing an entire message store and maintaining synchronization is a desirable goal for an email client 
component. Conventional prior art email client components have sought to achieve this goal even when it resulted in 
significant adverse impact on protocol Performance. An aspect of the present invention is that it is able to minimize 
adverse protocol impact while achieving this goal by utilizing a deep hierarchy table. Conventional prior art email server 
components have not been able to provide a deep hierarchy table. 

[0097] Where email message stores are subdivided into email folders, those email folders may be organized into 
hierarchies. FIG. 12 shows an example of an email folder hierarchy. In FIG. 12, folder 1204 is asubfolderof folder 1203. 
Folder 1 203 is, in turn, a subfolder of folder 1 202. Folder 1 201 is a root folder. A root folder is not a subfolder of any 
other folder. All other folders are members of the folder hierarchy rooted at folder 1201 . Typically, each folder in a folder 
hierarchy does not have direct reference to every other folder. A folder may only have direct reference to its subfolders. 
A folder may also have direct reference to any folders of which it is a subfolder. In many cases, it may be that the only 
folder for which every folder has a direct reference is the root folder of the hierarchy. 

[0098] A deep hierarchy table may contain information about every folder in a folder hierarchy. Each folder may have 
a row in the deep hierarchy table. The information in the deep hierarchy table is such that it may be used to determine 
if the contents of an email folder has changed during a particular time period. The determination of change to an email 
folder during a particular time period may be implemented using a simple comparison of a copy of a folder's row taken 
at the beginning of the time period, to a copy of that folder's row taken at the end of the time period. In one embodiment, 
each row of the deep hierarchy table includes the following attributes: 
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Attribute Name 


Attribute Type 


Notes 


Folder ID 


FID 


The FID type comprises a global unique identifier (GUID) 
and a six byte serial number. This value may be used to 

1 mini i^lv irl^ntifv/ sin ^mnil frtlrl^r in thp onnt^vt nf nn ^nrmil 
uiiiLjuciy iLiciiLiiy dii ciiiciii ivjiuci iii liib ouiilcal kji ciii ciiidii 

network. 


PR_LOCAL_CO M M IT_TI M E_M AX 


Timestamp 


This timestamp is updated anytime the contents of the 
folder Is modified. 


PR_DELETED_COUNT_TOTAL 


QWORD 


This value is a count of the total number of items ever 
deleted from the folder. 



[0099] Attributes of an email folder's row in a deep hierarchy table may be updated whenever a change is made to 
the contents of a folder. For efficient implementation of a deep hierarchy table update, applicants have found that it is 
helpful to have quick and direct reference to the deep hierarchy table. At a minimum, applicants have found that there 
should be a small and predictable number of levels of indirection when trying to access the deep hierarchy table. For 
example, positioning a deep hierarchy table at an arbitrary level in a folder hierarchy would not provide for a predictable 
number of levels of indirection. In one embodiment of the present invention, a deep hierarchy table may be associated 
with the root folder of an email network user's email message store folder hierarchy for this reason. 
[0100] Communications between an email client component and an email server component may be divided into 
communication sessions. Loss of email message store synchronization may occur between sessions, for example, 
during a network connectivity interruption. In orderto re-establish email message store synchronization at the beginning 
of a communications session, some protocols for communicating with previous version email server components em- 
ployed a Synch Folder ROP for each folder In the folder hierarchy. Typically, the contents of some of the folders will not 
2^ have changed between sessions. A SynchFolder ROP with an unchanged folder as its target results in a "null synch." 
Although a "null synch" does not result in any folder changes being transferred to an email client component, it does still 
have an overhead associated with it, for example, a stateblob data object, which may be significant. 
[0101] FIG. 13 illustrates an embodiment of the invention that avoids such "null synch" results by utilizing a deep 
hierarchy table. In a first request 1301, email client component 501 sends a ROP (e.g., GetHierarchyTable) requesting 
a deep hierarchy table to email server component 502. In a first response 1302, a copy of the deep hierarchy table is 
provided to email client component 501. Typically, email client component 501 will have a previous copy of the deep 
hierarchy table. Email client component 501 may determine quickly which folders in user's email message store on email 
server component 502 have changed by utilizing a row by row comparison of the two copies. Next, ROPs (e.g., Synch- 
Folder) are employed to synchronize only those folders that have changed. Request 1343 and response 1304 may be 
repeated as necessary to synchronize the changed folders. Following successful synchronization, the email client com- 
ponent's copy of the deep hierarchy table may be updated to match the latest copy that was sent in response 1302. If 
email client component 501 does not have a previous copy of the deep hierarchy table, then all folders that have a row 
in the latest copy may be synchronized. 

[0102] Once synchronization of a usei^s email message store has been established, synchronization may be main- 
tained by periodically repeating the start of session steps described above (i.e., polling the email server component), 
but this scheme has disadvantages. For example, the polling period may be much shorter than a period between changes 
to a user's email message store. In that case, relatively many of the deep hierarchy table comparisons will indicate that 
no folders have changed. Such comparisons are, in effect, wasted effort, so a protocol that can avoid them may be more 
efficient. 

45 [0103] Some email networks include a facility for an email client component to subscribe to be notified by an email 
server component when, for example, the contents of a particular email folder changes. Some previous version email 
client components do use such a facility to maintain synchronization of a user's email message store by creating a 
separate subscription for change notifications associated with each folder in a user's folder hierarchy. In an embodiment 
of the present invention, an email client component may create only a single subscription for change notifications asso- 
ciated with the deep hierarchy table. A single subscription is more efficient because fewer ROPs are required to establish 
it and less server-side resources are consumed. 

[0104] With further reference to FIG. 13, when a most recent version email client component 501, in accordance with 
an aspect of the present invention, employs a GetHierarchyTable ROP in a first request 1301 at the beginning of a 
communications session with an email servercomponent 502, the email client component501 is automatically subscribed 
55 to change notifications associated with the deep hierarchy table that is returned in response 1302. When a change 
occurs to an email folder in a user's email message store at the email client component, for example, an email message 
is added to the folder, the deep hierarchy table is also updated as previously described. The change to the deep hierarchy 
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table triggers a notification alert 1305 to email client connponent 501. While the notification alert is In response to the 
subscription placed by request 1301 ; it is not part of an explicit request-response cycle. Thus, use of the notification 
system as provided by the present invention results in much less overhead for the email network. 
[0105] A single subscription may result in many notifications. In one embodiment, the alert is delivered using a con- 

5 nectlonless network transport mechanism, for example. User Datagram Protocol/Internet Protocol (UDP/IP), but any 
suitable network transport mechanism maybe used. In response to the alert, email client component 501 sends a request 
1306 containing a ROP (e.g., GetNotification) to email server component 502. In response 1307, any changed rows of 
the deep hierarchy table (i.e., rows corresponding to a changed folder that triggered the notification) are sent to email 
client component 501. Email client component 501 then employs ROPs (e.g., SynchFolder) to synchronize only the 

^0 folders that have changed. 

[0106] Multiple email client components may be subscribed for change notifications associated with the same data 
object (e.g., the same email folder), for example, to provide collaborative functionality. As illustrated by FIG. 18, email 
client components 1801, 1802 and 1803 are subscribed for change notifications associated with the same data object 
(not shown) located on email server component 1 804. Email client component 1 803 sends a ROP 1 805 to email server 

15 component 1804 that results in a change to the data object. As a result of the change, email server component 1804 
sends out change notifications 1806,1 807 and 1808 to email client components 1801 ,1 802 and 1803. Change notifications 
may carry little information beyond identifying the data object that has changed so that, for example, there may be no 
way for an email client component to determine that it was the cause of a particular change. If the data object is, for 
example, an email folder, change notifications 1 806, 1 807 and 1 808 may result in each email client component 1 801 , 1 802 

20 and 1803 initiating synchronization for the changed folder. Since email client component 1803 was, in this example, 
responsible for the change, the result will be a "null synch." 

[0107] For reasons previously discussed it may be desirable to eliminate synchronizations that result in a "null synch." 
However, the notification behavior described may not always be undesirable and some email client components may 
depend upon it. An aspect of the present invention is to provide for the ability of an email client component to configure 

25 a notification behavior of most recent version email server components in order to improve protocol performance while 
at the same time providing previous version email client components with unchanged notification behavior. 
[0108] FIG.19A depicts notification behaviorthatmay be provided by previous version email server components. FIG. 
19B depicts configurable notification behavior in accordance with an aspect of the present invention. If desired, a most 
recent email client component may indicate to an email server component that it is capable of the notification behavior 

30 in FIG. 19B, for example by supplying a flag with a request, in the example shown in FIG. 19B, an IGNORE_OWN flag. 
[0109] At step 1901, the next candidate from the set of subscribers to be notified is selected. At step 1904, the 
subscription is examined for the IGNORE_OWN flag. If the flag is not present, step 1904 branches to step 1 902, where 
a notification is sent to the candidate subscriber. If the flag Is found, step 1904 branches to step 1905, where the 
subscription is examined again to determine if the subscriber triggered this notification. This determination may be made, 

35 for example, by examining a communications session Identifier ("session ID") of the session that was used to place the 
subscription. A session ID, for example, may comprise a global unique identifier and a six byte serial number. The 
notification is also examined for the session ID associated with its cause. If the two match, then the notification is 
suppressed. A result is that an email client component that caused a notification will not also receive that notification. 
The subprocedure then proceeds to step 1903, described below. 

40 [01 1 0] If the subscriber did not trigger the notification, then the session ID associated with the subscription is not the 
same as the session ID associated with the cause of the notification, and step 1905 braches to step 1902, where the 
notification is sent. The process then proceeds to step 1903, where a determination is made whether there are more 
subscribers to be notified. If there are, the subprocedure returns to step 1901 , otherwise this subprocedure is finished. 
[01 11 ] As stated above, an email client component utilizing cache storage of email messages may request, for example 

45 via a ROP, synchronization of messages or other data objects between a local client data store and the data store 
available at the email servercomponent. The email client component may similarly request messages to be copied from 
the server store to the client store. In either event, the request may be made using a fast transfer mode. 
[0112] Typically, when messages or other data such as files are requested for synchronization or copying, the request 
(e.g., ROP) includes an indication of all the messages for which synchronization is desired. This list may be automatically 

50 constructed by an email server component by, for example, utilizing the stateblob feature described above. For previous 
version (prior art) email server components, an error in one message or data object in a ROP request would cause a 
failure of all items in the request. This process is shown in FIG. 14A, where a request containing a ROP (e.g., FXPrepare) 
is transmitted at step 1401 with a messagelD set designated for copying or synchronization. A fast transfer mechanism 
is set up at the email server component 502, and a fast transfer ID is transmitted to the email client component 501 at 

55 step 1402. The email client component 501 then requests copying or synchronization of the data objects through a 
request containing, for example, an FXGetBuffer ROP (step 1403). An error occurs with one or more of the messages 
or other data objects when the email server component 502 attempts to open the requested messages. Examples of 
errors include a message or a data object being corrupt, server failure, the email server component 502 being out of 
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memory, or a virus being detected for the data object. 

[01 1 3] After the error, the email server component 502 sends a fatal ROP error in the data streamed to the email client 
component 501 at step 1404. As such, the synchronization fails, the messages within the messagelD set are not syn- 
chronized or copied, and the stateblob or similar update information is not received by the email client component 501 . 
5 The email client component 501 then has to request the synchronization or copying of the data objects at another time. 
It is possible that, If an error is not fixed at the email server component 502, error messages may continue to be sent, 
and the messages within the messagelD set may never be synchronized or copied. 

[0114] In accordance with one aspect of the present invention, instead of a fatal ROP error, a most recent email server 
component may send error information regarding the particular data object (e.g., an email message) so that synch roni- 
^0 zation for only that data object fails. This feature pennits messages or other data objects within a ROP or other request 
to be transmitted and synchronized or copied even if a message or other data object having an error is included within 
the response. 

[0115] As one example of how to handle an object-specific error, a most recent email server component may send 
an error message in a data stream for the data object having an object error. In this example, for ease of reference, the 

15 error is referred to as FXErrorlnfo. If desired, as further described below, FXErrorlnfo may include information such as 
the message ID for the data object having the error, and additional information regarding why the message failed. 
[0116] FIG. 14B shows a synchronization in which an error occurs in a message M3. The error results in a FXGetBuffer 
response 1 405 including message , and message M2, followed by FXErrorlnfo, and then message M4. The FXErrorlnfo 
information permits the email client component 501 to know which message had an error, and to synchronize all other 

20 messages within the response. If the error message FXErrorlnfo includes infonnation about the reason for the error, the 
information may be acted upon accordingly by the client component, for example, by displaying an error message to a user. 
[01 1 7] The following table shows an example of the format that the FXErrorlnfo may take: 



FXErrorlnfo 


Attribute Name 


Attribute Type 


Notes 


Version 


WORD 


The version of this structure. 


Error code 


DWORD 




Message ID 


MID 


The MID type comprises a global unique identifier (GUID) and a six byte 
serial number. This is the message ID of the message that caused the error. 






Zero or more attributes may be added here. 


Auxiliary Field Size 


ULONG 


The size of the array to follow. 


Auxiliary Field 


BYTE array 


An unstructured array for communicating error details. 



[01 1 8] As can be seen, the example format includes a version attribute, an error code, and a messagelD. In addition, 
if desired, one or attributes may be added. Further, as stated above, an auxiliary field may be defined for communicating 
40 error details. As such, an attribute may be defined for dictating the field size of the error details (e.g., an array), and a 
field may be provided, which may be, for example, an unstructured array for communicating the error details. As stated 
above, the error details may be handled as desired by the email client component 501 . 

[0119] The FXErrorlnfo permits the synchronization of the first response to be complete, for example resulting in a 
stateblob or other information being provided to email client component 501 . Because the email client component is 
45 now synchronized through message M4, the next request 1406 for synchronization may result in a response 1407 having 
the messages after M4 (e.g., M5 and Mg). 

[0120] To indicate that an email client component 501 is a most recent version, and thus is capable of handling the 
FXErrorlnfo message, a flag may be defined, for example, FXRecoverMode, that may be transmitted with a ROP re- 
questing synchronization or copying. Other indications may be used for the email client component 501 to communicate 

50 to the email server component 502 that it is capable of handling the FXErrorlnfo message. 

[0121] When the email server component 502 sends one or more messages or other data objects to the email client 
component 501, the data stream to the email client component may be separated or defined by property tags (e.g., 
ptags). For example, a list of messages may include for each message a start message ptag and an end message ptag. 
Between the start and end ptags may be a property list ptag and a subject ptag, which may have the property of a string. 

55 The subject ptag may be followed by the subject itself. Other property tags may be included. 

[0122] In the case where an error occurs in transmitting a message, the FXErrorlnfo may be provided as a ptag, and 
may have binary properties, such as is defined by the table above. An example of a data stream follows having both a 
successful message and a message in which an error occurs. In the case where the error occurs, the end message 
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ptag is not used for that particular message and tlie ptag FXErrorlnfo is tlie last ptag for that nnessage. 

ptagMessageList Start 
ptagMessageStart 
ptagPropList 

ptagSubject [PT^STRING] 
"Re: Your email" 



15 ptagMessageEnd 

ptagMessageStart 



20 

ptagFXErrorlnfo [PT^BINARY] 

[Contents as described by table] 
ptagMessageStart 



30 ptagMessageEnd 
ptagMessageListEnd 

[0123] FIG. 15A shows steps that an email server component 502 may utilize to transfer messages to a previous 
35 version email client component 501. Beginning at step 1501 , the message set is prepared, for example by placing the 
message set in the fast transfer data store. At step 1502, the message begins streaming out, for example Immediately 
after being placed in the send buffer of the email server component 502. If an error occurs when streaming out the 
message, then a fatal ROP error is streamed out to the email client component 501 in step 1504. The subprocedure 
then ends. If, when streaming the message, an error does not occur, then at step 1503 a determination is made whether 
40 more messages are in the set. If so, the process loops back to step 1502, where the next message is streamed out If 
not, then the subprocedure ends. 

[01 24] FIG. 1 5B shows a procedure for handling a message set by a most recent version of an email server component 
502. The steps taken are different depending upon whether the email client component is a most recent version or a 
previous version. Steps 1501-1504 are steps taken with a previous version email client component, and are the same 

45 as the steps having the same reference numerals in the preceding paragraph. 

[0125] If, at step 1 502, an error is found in streaming the message, then a determination is made at step 1505 whether 
the request includes a flag, such as FXRecoverMode. If the request contains the flag, then the email client component 
501 is a most recent version, and step 1 505 branches to step 1506, where the FXErrorlnfo is streamed out to the email 
client component 501 . The process may then continue to step 1503. If the request does not include the flag, then step 

50 1 505 branches to step 1 504, where a fatal ROP error is streamed out. The subprocedure then ends. 

[0126] As can be seen, the presence of the flag in the request permits the streaming process to continue by allowing 
a streaming out of the FXErrorlnfo instead of failing and sending a fatal ROP error. The flag is sent by a most recent 
version of an email client component 501. Previous versions of email client components do not include the flag, and 
thus an error results in streaming out a fatal ROP error, as described above. 

55 [0127] If desired, in an alternative embodiment, the error message (e.g., FXErrorlnfo) may be sent out for particular 
properties of a message or other data object, Instead of for an entire message. For example, FXErrorlnfo may be sent 
out for the body of a message, or for an attachment to a message. The email client component 501 may then synchronize 
or copy properties that are successfully sent without an error, and only the properties having errors are not synchronized 
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or copied. 

[0128] Sometimes, a message or otiier data object may be of sufficient size that it spans multiple FXGetBuffer re- 
sponses. To handle such messages, the email client component 501 may include rollback logic so that it may dispose 
of any partially received message and then proceedto properly receive further messages after receiving an error message. 

5 [0129] At times, it may be desirable for an email client component to be provided feedback regarding the progress of 
the copying or synchronization of data objects such as email messages. In accordance with one aspect of the present 
invention, a most recent version of an email client component 501 may indicate that it is capable of handling progress 
modes, for example by sending aflag, such as PROGRESS_MODE to an email server component 502 when requesting 
synchronization or copying of data objects. In response, a most recent version of an email server component 502 may 

^0 send a variety of information along with messages, such as the total size of all of the messages, the total number of 
messages, and total size of each messages, or any one or combination of these. 

[0130] For example, as shown in FIG. 1 6A, for a previous version email client component 501 , in response to a fast 
transfer request (1601 and 1603)forasetof messages, the email client component 501 receives the messages. In FIG. 
16A, messages are received In two responses 1604 and 1606. In previous version email client components 501 that 

15 use a fast transfer mechanism, a progress indication of the messages being streamed to the client was not provided. 
[0131] However, as shown in FIG. 1 SB, is a response 1607to a requestfora message setbythe email clientcomponent, 
the email server component 502 may provide a total number of data objects to be transferred, and the total size of all 
data objects to be transferred. This information is represented by "Pan" FIG. 168. A most recent version of an email 
server component 502 may also supply the size of each message, indicated by "P^, Pg, P3, ..." in FIG. 168. In addition, 

20 if desired, the information associated with each message and with the entire group of the messages may include additional 
information regarding whether each message is FAI or an actual email message. In one embodiment, the information 
represented by "Pall" always sent in response to a fast transfer request, even if zero data objects are 

transferred, in order to simplify processing of the data stream. 

[01 32] An example of a form at for the size and number of all data objects being transferred is shown in the following table. 

25 



IncrSyncProgressMode 


Attribute Name 


Attribute Type 


Notes 


Version 


WORD (e.g., a 16 bit integer) 


The version of this structure. 


cAssocMsgs 


DWORD (e.g., a 32 bit integer) 


The number of FAI data objects to be transferred. 


1 1TotalAssocMsgSize 


QWORD (e.g., a 64 bit integer) 


The total size of all FAI data objects to be transferred. 


cNormalMsgs 


DWORD 


The number of email messages to be transferred. 


1 ITotalNormalMsgSize 


QWORD 


The total size of all emal 1 messages to be transferred. 



[0133] As can be seen, separate attributes may be defined for the number of FAI data objects, the total size of all FAI 
data objects, the number of email messages to be transferred, and the total size of all the email messages to be 
transferred. Other combinations and additional attributes may be added to the format as desired. 
[0134] The following table shows a format for the size and other information that may be supplied with each message. 



IncrSyncProgresslVlodePerMsg 


Attribute Name 


Attribute Type 


Notes 


Message Size 


LONG 


The size of the next message. 


FAI flag 


800L 


Indicates if the next message is FAI. 



[0135] As can be seen, the format includes the size of the next message and whether or not the next message is FAI. 
[01 36] FIGS. 1 7A and 1 78 show steps for streaming a message set in accordance with a previous version of the email 
components, and a most recent version of the email components, respectively. The steps in FIG. 17A are similar to 
steps 1501-1503 in FIG. 15A. For FIG. 17B, the PR0GRESS_M0DE flag has been sent, for example with a ROP, by 
a most recent email client component 501. After the message set is prepared at step 1701, a determination is made 
whether the flag is present. If so, then the progress data totals are sent in step 1 702, and the process then proceeds to 
step 1 502, where the first message is streamed. If the flag is not present, then step 1 701 branches directly to step 1 502. 
[0137] After the first message is streamed, the process proceeds to step 1 703, where a determination is made if the 
flag is available. If so, then step 1703 branches to step 1704, where the per message progress data is streamed. The 
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process then proceeds to step 1503, described earlier. If the flag Is not available, step 1703 branches directlyto step 1503. 
[0138] An exannple of the stream of data for a most recent server component sending data to a most recent client 
component is set forth below. The stream of data is similar to the stream of data described above, but additionally 
Includes ptags for progress totals data (ptaglncrSyncProgressMode), which may have, for example, binary properties. 
In addition, for each message, the per message progress data is supplied, for example, as ptaglncrSyncProgressMode- 
PerMsg. 

PtaglncrSyncProgressMode (PT^BINARY) 

{Contents as described by table] 
ptagMessageListStart 

PtaglncrSyncProgressModePerMsg [ PT^BINARY ] 

[Contents as described by table] 
ptagMes sageStart 
ptagPropList 

ptagSubject [PT_STRING] 
*^Re: Your email" 



ptagMessageEnd 

PtaglncrSyncProgressModePerMsg [PT_BIKARY] 

[Contents as described by table] 
ptagMessageStart 



ptagMessageEnd 

PtaglncrSyncProgressModePerMsg [PT_BINARY] 
[Contents as described by table] 



ptagMessageStart 



ptagMessageEnd 
p t agMe s s ageLi s t End 



[0139] In the example shown, the ptags including the progress totals data (ptaglncrSyncPmgressMode) and the ptags 
forthe message progress data (PtaglncrSyncProgressModePerMsg) are located before the list of messages, and before 
each message, respectively. However, the structure of the streaming of the data objects may be revised so that the 
progress data may be included within the messages or within the message list. It is further possible to revise the structure 
of the streaming of the data objects in order to eliminate ptags delimiting messages and/or message lists entirely. 
[0140] An email client component receiving the progress data may utilize this data to determine the progress of 
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synchronization or copying of data objects from the ennail server component, and may utilize the per message progress 
data to determine the progress of each individual message. This information may be helpful, for example, in monitoring 
real time information about the progress of a synchronization. 

[0141] There are several different character sets that may be used for storing an email message or other data objects. 

5 For example, ASCII Is most commonly used for storing English language characters. However, ASCII is not sufficient 
for storing characters for all languages, because It is based upon 8-bit characters. Thus, ASCII code can be used for 
only 256 characters, which is enough for English but not enough for languages that have more characters. Unicode, on 
the other hand, is a character set that uses 16 bits (two bytes) for each character, and therefore is able to include more 
characters than ASCII. Unicode can have 65,536 characters, and therefore can be used to encode almost all the 

^0 languages of the world. Unicode includes the ASCII character set within it. 

[0142] In general, previous versions of email client components 501 have a designated code page; or character set 
and/or language associated therewith. For example, a particular version of an email client component 501 may have a 
German code page, and another version may have an ANSI code page. At times, it may be desirable for an email client 
component 501 to receive emails in character sets other than the designated code page. In accordance with one aspect 

15 of the present invention, a most recent client component may force an email server component to provide all emails in 
Unicode. Once the emails are received by the email client component 501 , the Unicode emails may be converted to the 
client's code page, or may alternatively be maintained in Unicode format. 

[0143] To indicate that an email client component 501 calls for emails to be provided in Unicode, the email client 
component 501 may, for example, provide a flag, such as FORCEUNICODE, to the email server component 502. The 
20 flag may be provided with a request, such as a ROP. If the email server component 502 is a most recent version, the 
email server component 502 can provide a Unicode version of the email, if available, or can convert email messages in 
other character sets to Unicode. 

[0144] FIG. 20 shows steps for providing a particular character set for a message in accordance with one aspect of 
the present invention. Beginning at step 2001 , the email server component 502 retrieves a message from its data store. 
25 At step 2002, a detennination is made whether the FORCEUNICODE flag is present. If not, then step 2002 branches 
to step 2003, where the email server component 502 provides the email message in the email client component's 
designated code page, converting if necessary. 

[0145] If the FORCEUNICODE flag is present, then step 2002 branches to step 2004, where a determination is made 
whether the message is stored as Unicode. If so, step 2004 branches to step 2005, where the message is provided to 
30 the email client component 501 in the Unicode character set. If the message is not stored in Unicode, then step 2004 
branches to step 2006 where the message is converted to Unicode, and then the process continues to step 2005, where 
the message is provided to the email client component in Unicode. 

[0146] All references. Including publications, patent applications, and patents, cited herein are hereby incorporated 
by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by 
35 reference and were set forth In its entirety herein. 

[0147] The use of the terms "a" and "an" and "the" and similar referents in the context of describing the invention 
(especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless 
otherwise indicated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "con- 
taining" are to be construed as open-ended terms (i.e., meaning "including, but not limited to,") unless otherwise noted. 

40 Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to 
each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated 
into the specification as if it were individually recited herein. All methods described herein can be performed in any 
suitable order unless othenwise indicated herein or otherwise clearly contradicted by context. The use of any and all 
examples, or exemplary language (e.g., "such as") provided herein, is intended merely to better illuminate the invention 

45 and does not pose a limitation on the scope of the invention unless otherwise claimed. No language in the specification 
should be construed as indicating any non-claimed element as essential to the practice of the invention. 
[0148] Preferred embodiments of this invention are described herein, including the best mode known to the inventors 
for carrying out the Invention. Variations of those preferred embodiments may become apparent to those of ordinary 
skill in the art upon reading the foregoing description. The Inventors expect skilled artisans to employ such variations 

50 as appropriate, and the Inventors intend for the invention to be practiced otherwise than as specifically described herein. 
Accordingly, this invention includes all modifications and equivalents of the subject matter recited in the claims appended 
hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible 
variations thereof is encompassed by the invention unless otherwise indicated herein or othen^ise clearly contradicted 
by context. 

55 The following is a list of further preferred embodiments of the invention: 

Embodiment 1 . A data packet embodied on a computer readable medium comprising: 
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a first data field identifying an ennail client component; 

a second data field including a request for a plurality of email data objects; and 

athird data field including an indication that the email client component is capable of handling progress mode data. 

Embodiment 2. The data packet of embodiment 1, wherein the progress mode data includes a size of each of the 
email data objects. 

Embodiment 3. The data packet of embodiment 1 , wherein the indication comprises a flag included with the request. 
Embodiment 4. The data packet of embodiment 1 , wherein the request comprises a request for synchronization of 
a folder in which the email data objects are located. 

Embodiment 5. The data packet of embodiment 1 , wherein the request comprises a request for a copy of email 
messages. 

Embodiment 6. The data packet of embodiment 1 , wherein the progress mode data includes the size of the plurality 
of the data objects. 

Embodiment 7. The data packet of embodiment 1 , wherein the progress mode data includes the number of folder 
associated information (FAI) objects in the plurality. 

Embodiment 8. The data packet of embodiment 7, wherein the progress mode data includes the size of the total 
folder associated information (FAI) objects in the plurality. 

Embodiment 9. The data packet of embodiment 1, wherein the progress mode data includes the number of email 
messages in the plurality of email data objects. 

Embodiment 1 0. The data packet of embodiment 9, wherein the progress mode data includes the size of the total 
email messages in the plurality. 

Embodiment 1 1 . The data packet of embodiment 1 , wherein the progress mode data further includes whether each 
object is a folder associated information (FAI) object. 

Embodiment 12. A computer-readable medium having computer-executable instructions, the instructions compris- 
ing: 

receiving, from an email client component, a request for a plurality of email data objects and an indication that 

the email client component is capable of handling progress mode data; 

in response to the request and the indication, retrieving the plurality of email data objects; and 

providing progress mode data to the email client component along with the plurality of data objects, the progress 

mode data comprising a size of each of the email data objects. 

Embodiment 1 3. The computer-readable medium of embodiment 1 2, wherein the indication comprises af lag included 
with the request. 

Embodiment 14. The computer-readable medium of embodiment 12, wherein the request comprises a request for 

synchronization of a folder in which the email data objects are located. 

Embodiment 15. The computer-readable medium of embodiment 12, wherein the request comprises a request for 
a copy of email messages. 

Embodiment 1 6. The computer-readable medium of embodiment 1 2, wherein the progress mode datafurther includes 
the size of the plurality of the data objects. 

Embodiment 1 7. The computer-readable medium of embodiment 1 2, wherein the progress mode datafurther includes 
the number of folder associated information (FAI) objects in the plurality. 

Embodiment 1 8. The computer-readable medium of embodiment 1 7, wherein the progressmode datafurtherincludes 

the size of the total folder associated information (FAI) objects in the plurality. 

Embodiment 19. The computer-readable medium of embodiment 12, wherein the progress mode datafurther includes 
the number of email messages in the plurality of email data objects. 

Embodiment20. The computer-readable medium of embodiment 1 9, wherein the progressmode datafurtherincludes 
the size of the total email messages in the plurality. 

Embodiment21 .Thecomputer-readable medium of embodiment 12, wherein the progress mode data further includes 
whether each object is a folder associated information (FAI) object. 

Embodiment 22. A computer-readable medium having computer-executable instructions, the instructions compris- 
ing: 

receiving, from an email client component, a request for a plurality of email data objects and an indication that 
the email client component is capable of handling progress mode data; 

in response to the request and the indication, retrieving the plurality of email data objects; and 
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providing progress mode data to tine email client component along with the plurality of data objects, the progress 
mode data comprising a size of the plurality of the email data objects. 

Embodiment 23. The computer-readable medium of embodiment 22, wherein the indication comprises aflag included 
5 with the request. 

Embodiment 24. The computer-readable medium of embodiment 22, wherein the request comprises a request for 
synchronization of a folder in which the email data objects are located. 

Embodiment 25. The computer-readable medium of embodiment 22, wherein the request comprises a request for 
a copy of email messages. 

^0 Embodiment26.Thecomputer-readablemediumofembodiment22,whereintheprogressmodedatafurtherincludes 

the size of each of the plurality of the data objects. 

Embodiment27.Thecomputer-readable medium of embodiment 22, whereintheprogressmodedatafurtherincludes 
the number of folder associated information (FAI) objects In the plurality. 

Embodiment28. The computer-readable medium of embodiment 27, wherein the progress mode datafurther includes 
15 the size of the total folder associated information (FAI) objects in the plurality. 

Embodiment29.Thecomputer-readable medium of embodiment 22, wherein the progress mode data further includes 
the number of email messages in the plurality of email data objects. 

EmbodimentSO. The computer-readable medium of embodiment29, wherein the progress mode data further includes 
the size of the total email messages in the plurality. 
20 EmbodimentSI .Thecomputer-readablemediumofembodiment22,whereintheprogressmodedatafurtherincludes 

whether each object is a folder associated information (FAI) object. 
Embodiment 32. A computer-implemented method, comprising: 

sending, from an email client component, a request for a plurality of email data objects and an indication that 
25 the email client component is capable of handling progress mode data; 

at an email server component, in response to the request and the indication, retrieving the plurality of email 
data objects and progress mode data for the plurality of email data objects; and 

30 at the email client component, receiving the progress mode data and utilizing the progress mode data to monitor 

transmission progress of the plurality of data objects to the email client component. 

Embodiment 33. The method of embodiment 32, wherein the progress data comprises a size of the plurality of the 
email data objects. 

35 Embodiment 34. The method of embodiment 32, wherein the progress mode data comprises the size of each of the 

plurality of the data objects. 

Embodiment 35. The method of embodiment 32, wherein the progress mode data comprises the number of folder 
associated information (FAI) objects in the plurality. 

Embodiment 36. The method of embodiment 35, wherein the progress mode data comprises the size of the total 
40 folder associated information (FAI) objects in the plurality. 

Embodiment 37. The method of embodiment 32, wherein the progress mode data comprises the number of email 
messages in the plurality of email data objects. 

Embodiment 38. The method of embodiment 37, wherein the progress mode data comprises the size of the total 

email messages in the plurality. 
45 Embodiment 39. The method of embodiment 32, wherein the progress mode data further includes whether each 

object is a folder associated information (FAI) object. 

Embodiment 40. A computer-readable medium having computer-executable instructions, the instructions compris- 
ing: 

50 receiving, from an email client component, a plurality of subrequests within a request, each of the subrequests 

requesting an operation at an email server component and including size information; and 

in response to each subrequest: 

55 if the size information includes a size limit inside a range expected by the email server component, then limiting 

a response to the size limit; and 

if the size information includes a size limit outside a range expected by the email server component, then looking 
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for a new size limit in the size information. 

Embodiment 41. The computer-readable medium of embodiment 40, further comprising, if the size information 
includes a size limit outside a range expected by the email server component, filling a buffer for the email server 
component with the response. 

Embodiment 42. A computer-implemented method, comprising: 
at an email client component: 

creating a plurality of subrequests within a request, each of the subrequests requesting an operation at an email 
server component and including size information; and 

sending the request to an email server component; at an email server component: 

receiving the request; and 

in response to each subrequest: 

if the size information includes a size limit inside a range expected by the email server component, then limiting 
a response to the size limit, and 

if the size information includes a size limit outside a range expected by the email server component, then looking 
for a new size limit in the size information. 

Embodiment 43. The method of embodiment 42, further comprising, if the size infoimation includes a size limit 
outside a range expected by the email server component, filling a buffer for the email server component with the 
response. 

Important Note: 

[0149] While the attached claims relate to a preferred aspect of the present invention, the applicant wishes to reserve 
the right to file one or several further divisional applications at a later point in time for other aspects disclosed in the 
application. Those further applications will be divided out from the present divisional application. By this statement, the 
public is herewith informed that more divisional applications relating to different subject matter may follow. 



Claims 

1. A data packet embodied on a computer readable medium comprising: 

a first data field identifying an email client component; 

a second data field including a request for a plurality of email data objects; and 

a third data field including an indication that the email client component is capable of handling an email data 
object having an error. 

2. The data packet of claim 1 , wherein the indication comprises a flag included with the request. 

3. The data packet of claim 1 , wherein the request comprises a request for synchronization of a folder in which the 
email data objects are located. 

4. The data packet of claim 1 , wherein the request comprises a request for a copy of email messages. 

5. A computer-readable medium having computer-executable instructions, the instructions comprising: 

receiving, from an email client component, a request for a plurality of email data objects and an indication that 
the email client component is capable of handling an email data object having an error; and 
in response to the request and the indication, retrieving the plurality of email data objects; and 
for each of the email data objects: 
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if no error occurs in opening the ennail data object, transnnitting the ennail data object to the email client 
component, and 

if an error occurs in opening the email data object, transmitting an error message to the email client com- 
ponent. 

6. The computer-readable medium of claim 5, wherein the error message comprises version information for the email 
data object. 

7. The computer-readable medium of claim 6, wherein the version information comprises a 16 bit integer. 

8. The computer-readable medium of claim 5, wherein the error message comprises identification information for the 
email data object. 

9. The computer-readable medium of claim 8, wherein the identification information comprises a 32 bit integer. 

10. The computer-readable medium of claim 8, wherein the identification information comprises a globally unique iden- 
tifier (GUID) and a six byte serial number. 

11. The computer-readable medium of claim 5, wherein the error message comprises information regarding the error. 

12. The computer-readable medium of claim 11, wherein the information regarding the error includes size of an array 

for communicating error details. 

13. The computer-readable medium of claim 5, wherein the indication comprises a flag included with the request. 

14. The computer-readable medium of claim 5, wherein the request comprises a request for synchronization of a folder 
in which the email data objects are located. 

1 5. The computer-readable medium of claim 5, wherein the request comprises a request for a copy of email messages. 

16. A computer-readable medium having computer-executable instructions, the instructions comprising: 

sending, from an email client component, a request for a plurality of email data objects and an indication that 
the email client component is capable of handling an email data object having an error; and 
for each of the email data objects: 

If the email data object does not contain an error, receiving the email data object and copying the email 
data object at the email client component, and 

if the email data object does contain an error, receiving an error message. 

17. The computer-readable medium of claim 16, wherein the error message comprises an identification for the email 
data object. 

18. The computer-readable medium of claim 1 6, wherein the eror message comprises information regarding the error. 

19. The computer-readable medium of claim 16, wherein the indication comprises a flag included with the request. 

20. The computer-readable medium of claim 1 6, wherein the request comprises a request for synchronization of a folder 
in which the email data objects are located. 

21. The computer-readable medium of claim 1 6, wherein the request comprises a request for a copy of email messages. 

22. A data packet embodied on a computer readable medium comprising: 

a first data field identifying identification information regarding an email data object; and 
a second data field including an error code for the email data object. 

23. The data packet of claim 22, further comprising a third data field representing version information for the email data 
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object. 

24. The data packet of claim 23, wherein the third data field comprises a 16 bit integer. 

25. The data packet of claim 22, further comprising a third data field representing identification information for the email 
data object. 

26. The data packet of claim 25, wherein the third data field comprises a 32 bit integer. 

27. The data packet of claim 25, wherein the third data field comprises a globally unique identifier (QUID) and a six byte 
serial number. 

28. The data packet of claim 22, further comprising a third data field including information regarding an error related to 
the error code. 

29. The datapacketof claim 28, wherein the information regardingtheerrorincludesasizeof an array for communicating 
error details. 
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